[レポート] LayerXのプロダクト開発と組織 #pmconf2021

[レポート] LayerXのプロダクト開発と組織 #pmconf2021

Clock Icon2021.11.08

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

2021年10月26日(火)、プロダクトマネジメントに携わる人たちが共に学び、切磋琢磨するイベント『プロダクトマネージャーカンファレンス2021』がオンライン形式で開催されました。

当エントリでは、ブレイクアウトセッション『LayerXのプロダクト開発と組織』の参加(視聴)レポートをお届けします。

目次

 

セッション概要

セッション概要は以下の通りです。

[タイトル]
LayerXのプロダクト開発と組織

[登壇者]
・福島 良典氏(株式会社LayerX / 代表取締役 CEO)

[セッション概要]
LayerXのSaaSプロダクト「LayerX インボイス」の開発組織立ち上げと今後の展開の話を中心に、ブロックチェーン事業からの事業ピボット、それに伴う人と組織の変化についてお話します。また、自身が経験してきた2度の起業経験を踏まえた「プロダクト開発と組織」について失敗談も含めお伝えします。
(※以上、公式サイトより引用)

 

セッションレポート

 

はじめに

  • 本日のコンセプト
    • "ダサい"失敗を語ろう
      • かっこいい情報は書籍に書いてある。正論はそっちを読もう
      • 実際のところは事業アングルや人的資源の制約、「僕たちは特別」という奢りなどからダサい失敗をいっぱいするもの。それを語ります
    • スタートアップの"リアル"を語ろう
      • 不確実な情報の中で走りながら決めなくてはいけない、という状況での「やらかし」
  • 自己紹介
  • 企業(LayarX)紹介
    • 上場企業の創業経験者達で固める経験豊富なチーム
    • 経営のエンジニア比率が高いテックカンパニー
    • SaaS事業/FIntech事業/Privacy Tech事業

 

LayerXがしてきた"ダサい"失敗

  • 前提とする「組織の理想像」
    • 意思決定がヘルシーになされる構造
    • 顧客の課題が正しく吸い上げられ、顧客と開発の距離が近い
    • 課題に対するソリューションのデリバリーが速い
    • 実験の結果が素早くフィードバックされ、改善が回ること
  • LayerXがやってしまった、4つの『ダサい失敗』
    • ポジショントークの罠
    • 売上の罠(提供価値とのギャップ)
    • PMFの罠
    • 阿吽の呼吸の罠
  • LayerXの組織変遷:コンサル・PJ型の組織からプロダクト型の組織にピボットしている
    • コンサル・PJ型の組織の場合、案件が増える毎にメンバーをアサイン
    • 現在はプロダクトを作って売る形にシフトしている

 

コンサル事業時代に陥った「罠」

ポジショントークの罠

  • コンサル・PJ型の組織時代、ブロックチェーンコンサル(ベンダー)立ち上げ期の話
  • どういう諸条件、商流で入るのかが大事、という内容
  • ポジショニングが意思決定を規定してしまう
    • "ブロックチェーンに強いLayeyX"というポジショニング。この条件で入ると、色々厳しい状況があった
    • LayeyXがやりたいのは事業、先方はベンダー的な役割を求めていた
    • ブロックチェーンコンサル的な立場で入ると『初期段階ではブロックチェーン要らないですよね』という提案になるケースも:お客様のためにはなってもLayerXの売上にはならない
    • 先方の意向(ブロックチェーンに強いLayeyXさんに発注する理由が欲しい)もあり、コードを書くよりも説得資料をつくる時間が長くなってしまった
    • 結果「ブロックチェーンコンサルやめよう」となった

売上の罠

  • コンサル・PJ型の組織時代、ブロックチェーンコンサル(ベンダー)拡大期の話
  • 売上≠提供価値
    • 世の中のブロックチェーンPoCブームに乗る形で売上は絶好調
    • 単体で使うと単なる高価なトランザクションDBに過ぎない
      • 結果PoC止まりに
    • 開発需要は旺盛、案件はどんどん来るのでやめられない
    • 売上の質
      • 単に需給の関係で、開発資源が希少だから上がっている売上
      • 一方、プロダクトが提供してくれる提供価値に付く売上(こっちが本質的な売上)
        • こっちは急には作れない、提供価値は少しずつ上がっていくもの
      • 短期では「需給の売上」の方が早く作れてしまうが、いずれも同じ「売上」として計上されてしまう
      • 前述の「ポジショントークの罠」と組み合わせていくと、状況によっては「地獄」となる

教訓

  • 「ポジショントークの罠」から得られたこと
    • プロダクト型組織でリスクを取る
  • 「売上の罠」から得られたこと
    • 売上≠提供価値
      • 売上が伸びているとそのビジネスは正しいと正当化されがち
    • 売上の質を追う

教訓からのLayerXの決断

  • 「売上を捨てて、プロダクト型組織へ」
  • 課題を変えず、リスクのとり方を変更
    • ブロックチェーンコンサルから、現在の3事業へPivot
      • コンサルを得て経た「リアルな課題」にフォーカス
      • 技術選定にとらわれないポジションに
      • 業界をむやみに広げない
        • プロダクトを中心に課題を深堀り、徹底的に強みを作る
    • 売上を捨ててプロダクト型組織へと転換
      • プロダクト型の本質
        • 課題や技術選定に対する自由度の高さ
        • 「ヘルシーな意思決定」が可能に
        • 売上の質:メンバーが優秀(希少)だから売上が付くのでは無く、提供価値に売上が付く。提供価値として開発したものがプロダクトに蓄積されていく

 

プロダクト型組織移行後に陥った「罠」

PMFの罠

Product Market Fit(以下PMF)とは、「プロダクト(製品やサービス)がマーケットにフィット(適合)し、受け入れられている状態」を指す。 平たく言えば、「プロダクトに満足して、継続利用してくれるユーザーが右肩上がりで増加している状態」のことだ。 投資家が投資するかどうか判断する場合も「PMFを達成しているか」を基準にする場合も多い。

  • プロダクト型組織への移行後の話
  • PMFが終わったらアクセルを踏もう → アクセルを踏んで初めてPMFに到達する
    • 本が語る理想的なPMFと現実
      • 理想:こういうのは実際あるのか?
        • 「なくなると困る」が7割
        • 100人聞いたら15人が「お金を払う」
        • LTV/CPA > 3
      • 現実:
        • 紙芝居では真の課題は引き出せない
        • リップサービスの「使いますよ」「お金払いますよ」
        • アクセルを踏まないと、新しい未知の顧客に出会えない
    • 理想的PMFに達していない不安
      • 何度も「撤退」のワードが頭をよぎる
    • 「アクセルを踏んでみて初めてPMFに到達」が正しい
      • 「鶏と卵」な問題はあるが、氏は「アクセルを踏む」が卵だと考えている
      • 1年は踏ん張らないとダメだ、と思い頑張る→競合環境の変化などもあり、全くPMFしてないのにアクセルを踏まないといけなくなった(ベンチャーあるある)→踏んだ→何となくの自信が芽生え「PMFしたかも?」と思う事も多くなってきた
      • 躊躇わずにアクセルは踏んでいこう

阿吽の呼吸の罠

  • プロダクト型組織への移行後の話/まだ解決していない問題でもある
  • 文脈を知るゆえの速さ、知るゆえのスケールのしなさ
    • PMF以前から見ているメンバーとそうでないメンバーの文脈差、ドメイン知識の差
    • 「俺たちは特別」という奢り
    • 「情報を記録している」という奢り
    • 「優秀な人を採用しているから」という奢り
    • セオリーに従う
      • 暗黙知の徹底排除

 

LayarXのプロダクト開発の組織文化

組織概要

  • 組織としてブレないために、組織のミッションを決めた
  • 阿吽の呼吸で支えられてきた部分を解く、暗黙知であった部分を新しいメンバーにとって自明となるようにミッションレベルで落とし込んだ
  • メンバー比率
  • メンバーのバックグラウンド
  • 採用計画

カスタマーサクセスにこだわる

  • 「カスタマーサクセス」に徹底的にこだわる
    • 「契約したが利用していない状態」は最悪
    • 業務フローに乗り、効果が出ることに徹底的にこだわる形とした
    • カスタマーサクセスは職種では無く、チーム全員で取り組むべき概念であり達成すべき状態
    • 定量・定性の両面からモニタリングを行い、お客様の成功に向き合う
      • 【定量】プロダクトKPI
        • 契約前からKPIを設定し、理想のユーザー像定義、定量的にモニタリングを実施
      • 【定量&定性】モニタリング&ヒアリング
        • エンジニア職、ビジネス職を問わず、自律的に分析とモニタリングを実施。異常があれば課題のヒアリングも行った
      • 【定性】お客様のリアルな声を聞き、プロダクトを改善する
        • 商談や月次フィードバックは動画(※要許諾)でチームに共有
        • エンジニアが同席するケースも
    • 解約率と幽霊解約
      • 共にゼロで確かな価値提供、高い満足度を実感
        • 幽霊解約=契約はしているものの、請求書を全くアップしていない状態

開発文化

  • 「爆速開発」=高速な顧客課題、事業の検証と組織的学習
  • 爆速を生む開発スタイル:基本は王道のスクラム開発(2週間1スプリント)+爆速開発のための工夫を実施
    • 「自律的で、背中を預け合う並列開発」
    • 「デモ駆動開発」
      • 動くモノが正義、動くモノがあってはじめて議論出来る
      • コンサルをやっていた時に資料ばっかり作っていたことを反省
    • 「使われないものを作らない」
  • 技術スタックの今:合理的な意思決定を行った結果

改めて、こうやって書いてみると変わった部分は少ない気がする。もちろんR&DではRustやIntel SGXなども登場するけど。SaaSや金融事業においては丁寧に普通の技術を普通に使い、巨人の肩に上手く乗ることで技術で悩む部分を減らして、とにかく顧客への価値とはなんぞやを突き詰めている。

— 松本 勇気 | LayerXはSaaSとFintechの会社です (@y_matsuwitter) August 7, 2021

  • 技術面でのこだわり
    • 爆速開発≠雑。こだわるポイントと、やりすぎないポイントに強弱を付ける
      • アーキテクチャはシンプルに、PMFが見えたら作り込む
        • マネージドサービスの徹底活用
        • コアとノンコアの意識
      • スケールと開発速度の両立のため、設計には初期からこだわる。一方やりすぎない部分も決める
        • サービス特性上、セキュリティは初期段階から手を抜かずにきっちり設計・実装
        • スキーマ駆動開発
          • DBとAPIスキーマをベースにコードを生成し、実装の土台として開発スピードを底上げ
      • 資産化
        • インフラ、フロントパーツ、各種コードは徹底的に資産化して次のレバレッジを効かせる。
        • 「LayerXワークフロー」は資産を活かし、2ヶ月でリリース
  • エンジニアの気質
    • お客様にとって価値を届け続ける事にこだわる気質
      • 「事業を作る」
        • マーケティング、セールス、CS、全てのプロセスを含めて1つの「プロダクト」
        • ビジネス職と垣根を作らず議論に参加
      • 「お客様の声に応える」
      • 「新領域にチャレンジ」
      • 「ファクトベースで議論」
  • 情報の透明性へのこだわり
    • アウトプット=スキルx情報のアクセス性x組織リソースのアクセス性
      • 経営会議の議事録はフルオープン
      • 商談、フィードバック動画も全部アクセス可能
      • 各チームがオンボード資料を作成
      • 両代表が入社時オンボードにコミット

 

総括

  • (再掲)前提とする「組織の理想像」
    • 意思決定がヘルシーになされる構造
    • 顧客の課題が正しく吸い上げられ、顧客と開発の距離が近い
    • 課題に対するソリューションのデリバリーが速い
    • 実験の結果が素早くフィードバックされ、改善が回ること

 

まとめ

という訳で、プロダクトマネージャーカンファレンス2021のセッション『LayerXのプロダクト開発と組織』の視聴レポートでした。

Share this article

facebook logohatena logotwitter logo

© Classmethod, Inc. All rights reserved.